Celestin Apprentice 2/Apprentice-Release2.iso/Information/Digests/CSMP Digest/volume 1/csmp-v1-152.txt

Text File | 1994-12-08 | 47.1 KB | 1,156 lines | [TEXT/R*ch]

C.S.M.P. Digest             Sun, 02 Aug 92       Volume 1 : Issue 152

Today's Topics:

    Proposal for Mac Source code representation
    SendFinderOpen
    garbage sound from SndPlay



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  The most recent issues
are available from sumex-aim.stanford.edu [36.44.0.6] in the directory
/info-mac/digest/csmp.  If you don't have ftp capability, the sumex archive
has a mail server; send a message with the text '$MACarch help' (no quotes)
to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Gregory G. Woodbury)
Subject: Proposal for Mac Source code representation
Date: 17 Jun 92 07:00:22 GMT
Organization: Wolves Den UNIX

In the heat of the discussion about comp.sources.mac it becomes obvious
that there is a problem with the way that sources for Macintosh programs
are packaged.

On reflection this is obviously the result of the situation that current
Mac development environments provide a multi-mode form of handling the
fact that a Mac program consists of more than the ASCII codes of the
statements in the programming language in use -- there are resources
that are usually NOT composed in an ASCII plaintext form (via ResEdit),
and there is no plaintext way to describe such factors as code
segmenting and loader grouping.

I suggest that the Mac net.community needs to get together and define a
way to address this issue so that we can start sharing source code in a
uniform and portable manner.

As a beginning, here are some of my thoughts on the issue.

1.  Functions written in a source language can be published in ASCII
form.  There should be an agreement on the settings of tab positions, or
a header that describes the tab positions.  Certain characters can be
represented via something akin to the C backslash escape mechanism.

2.  The sources in ASCII can have a checksum or CRC-type value attached
to insure proper transmission of the source code.

3.  Binary data (like resources) should appear in standard .hqx form.
Something similar is a standard occurrence in sources appearing on the
comp.sources.x groups for binary based data.

4.  A tabular description syntax should be developed that describes code
segmentation/loader grouping information.

5.  Other things that I've missed should be nailed down.


It would not be to hard to develop a small application that can be
pointed at a set of files on the Mac that will examine the files and
generate the appropriate ASCII  form files and .hqx files for resources.
About the only thing to  be done by hand might be the segmentation
descriptions, and more knowledgeable folks than I might be able to
provide a means to automagically generate such information from an MPW
or THINK project file.

There is enough desire for Mac sources to be made available, that it is
well worth *our* effort to get this worked out so that they can be made
available.

The ball is in our court.

                    Greg Woodbury
- --
Gregory G. Woodbury @ The Wolves Den UNIX, Durham NC
UUCP: ...dukcds!wolves!ggw   ...duke!wolves!ggw           [use the maps!]
Domain: [e-mail]     [e-mail]
[The line eater is a boojum snark! ]           <standard disclaimers apply>

+++++++++++++++++++++++++++

From: [e-mail] (Charles B. Cranston)
Organization: UM Home for the Terminally Analytical
Date: Wed, 17 Jun 1992 17:06:12 GMT

In article <[e-mail]>,
[e-mail] (Gregory G. Woodbury) writes:

> In the heat of the discussion about comp.sources.mac it becomes obvious
> that there is a problem with the way that sources for Macintosh programs
> are packaged.
> ...
> 1.  Functions written in a source language can be published in ASCII
> form.  There should be an agreement on the settings of tab positions, or
> a header that describes the tab positions.  Certain characters can be
> represented via something akin to the C backslash escape mechanism.
> ...

This might be a good time to take a look at the character representation
standards being developed by the Internet community in support of the MIME
(Multipurpose Internet Mail Extension) standard:

RFC1341 MIME (Multipurpose Internet Mail Extension)
        Mechanisms for Specifying and Describing the Format of
        Internet Message Bodies

RFC1342 Representation of Non-ASCII Text in Internet Message Headers

RFC1345 Character Mnemonics & Character Sets

With the Macintosh's rich (i.e. more than ASCII) character set this could
be a big win.  Here's an abstract of 1345:

   "This memo lists a selection of characters and their presence in some
   coded character sets.  To facilitate the coded character set
   tabulations an unambiguous mnemonic for each character is used, and a
   format for tabulating the coded character sets is defined. The coded
   character sets are given names for easy reference.  A family of coded
   character sets called the mnemonic character sets and conversion
   between these coded character set without information loss is defined."

Also consider this quote from a letter-to-the-editor in Communications
Week (#407 June 15, 1992):

   "As co-author of the MIME specification I read your article on MIME
    with considerable interest. ...  MIME initially provides for use of
   the ISO 8859 family of charactersets in addition to ASCII ... it also
   sets up a registry so that additional character sets can be defined
   and registered in the future as they are needed. ...  Support for
   ISO 10646 will undoubtedly be added once it becomes a full standard.
   ...Ned Freed ... Innosoft International Inc."


Actually, one could probably build a Macintosh file "body type" for MIME
and get an ASCII text representation essentially free...


+++++++++++++++++++++++++++

From: [e-mail] (Lloyd Lim)
Date: 17 Jun 92 17:56:34 GMT
Organization: U.C. Davis - Department of Computer Science

In article <[e-mail]> duke.cs.duke.edu!wolves!ggw writes:
>
>3.  Binary data (like resources) should appear in standard .hqx form.
>Something similar is a standard occurrence in sources appearing on the
>comp.sources.x groups for binary based data.

Well, if we could post .hqx files into comp.sources.mac in the first place,
we wouldn't have this problem.  Unless things change, .hqx won't work
because it won't be accepted for posting.

We _could_ Derez the resources.  The result is plain text, except for any
8 bit characters that would have to be handled, just as with the source code.

>5.  Other things that I've missed should be nailed down.

This isn't a criticism; just more thoughts on how to get this to work...

Personally, I think it'd be easiest if we could use the tools we already
use: StuffIt and BinHex.  (StuffIt/BinHex also uses less bandwidth than
plain text.)  If someone who knows the process could put out a CFD and CFV
(or whatever) to change c.s.m., then it might be solved relatively quickly.
And then we could all spend our time more productively writing new games.  :-)

+++
Lloyd Lim               Internet: [e-mail]
224 Leach Hall          America Online: LimUnltd
U.C. Davis              AppleLink: LimUnltd
Davis, CA  95616        CompuServe: 72647,660

+++++++++++++++++++++++++++

From: [e-mail] (David Fry)
Date: 17 Jun 92 19:53:15 GMT
Organization: Harvard Math Department

In article <[e-mail]> duke.cs.duke.edu!wolves!ggw writes:
>In the heat of the discussion about comp.sources.mac it becomes obvious
>that there is a problem with the way that sources for Macintosh programs
>are packaged.
>
>On reflection this is obviously the result of the situation that current
>Mac development environments provide a multi-mode form of handling the
>fact that a Mac program consists of more than the ASCII codes of the
>statements in the programming language in use -- there are resources
>that are usually NOT composed in an ASCII plaintext form (via ResEdit),
>and there is no plaintext way to describe such factors as code
>segmenting and loader grouping.

Why is this necessary? If the answer is so that non-MacPeople will
allows us to send our Mac source to comp.sources.mac, I say "tough for
them," let's just send .hqx files.  If there's something so general
about Mac source listing that it would aid non-MacPeople, then it
could just be listed separately without resources, linking, etc.
If the USENET gods insist we can't send .hqx files to
comp.sources.mac, then send them to comp.binaries.mac or some other
forum.  Make them available for ftp.

For those that really want to have ASCII representations, MPW programmers
can supply a Makefile that describes all the linking steps.  THINK
users could just write down that information, or use an FKEY out there
that collects the information from an open project file.  As for
resources, MPW has Rez and DeRez and THINK has SARez and SADeRez
(which are compatible I believe) to create ASCII representations of
resources.  Maybe a tabular systems of describing the linking would be
nice, but I really think it's a lot of effort for nothing.

Actually, THINK project files are just resource forks anyway, so you could
SARez them as well. :-)  If SARez is used to its greatest use, this
might even be the best way to distribute link information.

I know there are other environments out there, but they are vastly
outweighed by MPW and THINK.

>I suggest that the Mac net.community needs to get together and define a
>way to address this issue so that we can start sharing source code in a
>uniform and portable manner.
>
>As a beginning, here are some of my thoughts on the issue.
>
>1.  Functions written in a source language can be published in ASCII
>form.  There should be an agreement on the settings of tab positions, or
>a header that describes the tab positions.  Certain characters can be
>represented via something akin to the C backslash escape mechanism.
>
>2.  The sources in ASCII can have a checksum or CRC-type value attached
>to insure proper transmission of the source code.
>
>3.  Binary data (like resources) should appear in standard .hqx form.
>Something similar is a standard occurrence in sources appearing on the
>comp.sources.x groups for binary based data.

If we're going to give in and post Binhex data for this, why not just
distribute the whole thing in binhex?

>4.  A tabular description syntax should be developed that describes code
>segmentation/loader grouping information.
>
>5.  Other things that I've missed should be nailed down.

These are all good ideas, but I again wonder why this is necessary. I
think it's the habit of the net.community to build structure and
formalism just because we enjoy the process. I think it would be cool to have
a program that I could point at a set of files and have it produce an
ASCII representation, but I don't think the value of this is worth the
effort, not to mention all the future effort of people straining to
conform to it, and the future nitpicking of people who don't conform
to it.

As an example of the net getting carried away with itself consider the
alt.binaries.* groups which have associated alt.binaries.*.d
discussion groups.  You're not supposed to post a text file to the binary
group except under penalty of death, but people -- both those that
know better and those that don't -- do all the time.  Now there's
continual picking at people who post text files to the binary
groups, including one person who has an automatic system of sending
mail to people who do it telling them not to.  Who cares???!!
How much effort has been spent on this silly issue?
Let's not fall into a similar trap with this one.

Besides, I don't think it would induce people to distribute any more
Mac sources.

>There is enough desire for Mac sources to be made available, that it is
>well worth *our* effort to get this worked out so that they can be made
>available.

I think people can make their sources available already.

David Fry                               [e-mail]
Division of Applied Sciences            [e-mail]
Harvard University                      ...!harvard!huma1!fry
Cambridge, MA  02138

+++++++++++++++++++++++++++

From: [e-mail] (Steve Dorner)
Organization: University of Illinois at Urbana-Champaign
Date: Fri, 19 Jun 1992 16:51:52 GMT

[e-mail] (David Fry) writes:
>If the USENET gods insist we can't send .hqx files to comp.sources.mac

The only god we have to worry about is the moderator of comp.sources.mac.

I, too, think it's silly to ban .hqx files from the group.
- --
Steve Dorner, U of Illinois Computing Services Office
Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner

+++++++++++++++++++++++++++

From: [e-mail] (Christoph Sold)
Organization: Universitaet Kaiserslautern
Date: Fri, 19 Jun 1992 20:18:02 GMT

In article <[e-mail]> [e-mail]
 (Gregory G. Woodbury) writes:
>From: [e-mail] (Gregory G. Woodbury)
>Subject: Proposal for Mac Source code representation
>Date: 17 Jun 92 07:00:22 GMT

>In the heat of the discussion about comp.sources.mac it becomes obvious
>that there is a problem with the way that sources for Macintosh programs
>are packaged.

> [...]

>I suggest that the Mac net.community needs to get together and define a
>way to address this issue so that we can start sharing source code in a
>uniform and portable manner.


    This seems to be a big problem. As a sabbatical MPW user, I love
    projector databases. Another sabbatical user will just die for
    Think's project files. Yet another one will write code using
    a the PD Oberon from ETH. All of these files use plain ASCII
    to represent the source text in the data fork, and put their
    special resources into the resource fork. Thus, plain ASCII will
    loose information.

>As a beginning, here are some of my thoughts on the issue.

>1.  Functions written in a source language can be published in ASCII
>form.  There should be an agreement on the settings of tab positions, or
>a header that describes the tab positions.  Certain characters can be
>represented via something akin to the C backslash escape mechanism.

    I don't agree. Event I use different tab settings for assembler,
    Pascal, and C sources.

>2.  The sources in ASCII can have a checksum or CRC-type value attached
>to insure proper transmission of the source code.

    Why define just another checksum standard? MacBinary does this
    all for you, why don't you want to use it?

> [...]

>4.  A tabular description syntax should be developed that describes code
>segmentation/loader grouping information.

    I agree. I just hate Think C sources without any segmentation
    notices. (Think uses its project file to segment the source.)

>5.  Other things that I've missed should be nailed down.

    As of today, exchanging source works fine for me. If I got MPW
    source, bingo! all's well. Think C or Pascal sources will be
    properly read when transmitted as binary. Plain text will work,
    too. The one and only thing I beg for: Always use a standard
    compressor to archive your source into one file, .hqx it and
    off it goes.

> [...]
>The ball is in our court.

    I returned it. Write on!

- -Christoph

Christoph P. Sold                   CATS Software GmbH
                                    Mussbacher Landstr.2
                                    W-6730 Neustadt (Weinstrasse)
[e-mail]     Germany

"If an apple is fun, what the heck is an appletree?"

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Neeracher)
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: Mon, 22 Jun 1992 14:45:57 GMT

In article <[e-mail]> [e-mail] (David Fry) writes:
>In article <[e-mail]> duke.cs.duke.edu!wolves!ggw writes:
>[Remarks that I agree with deleted]
>
>For those that really want to have ASCII representations, MPW programmers
>can supply a Makefile that describes all the linking steps.

No. It is not possible to write a Makefile for MPW using purely ASCII
characters, since the dependence sign (The Integral/Folder sign) is not ASCII.
I think this example alone should show clearly enough that any ASCII
representation for Macintosh sources necessarily has to be artificial and
unreadable for humans.

Another argument that especially applies to us foreign language developers:
Many of us appreciate the fact that the Macintosh has a standard set of
accented characters, and would hate to give up their freedom of writing
comments and string literals in their native language for the sake of ASCII
compatibility.

>  As for
>resources, MPW has Rez and DeRez and THINK has SARez and SADeRez
>(which are compatible I believe) to create ASCII representations of
>resources.  Maybe a tabular systems of describing the linking would be
>nice, but I really think it's a lot of effort for nothing.

I agree. Most Mac programs are inherently nonportable to other architectures,
anyway (Hey, that SPARCstation on my desk is supposed to be a computer and
doesn't even understand Gestalt()).

>These are all good ideas, but I again wonder why this is necessary.

So do I. Here are my thoughts on the issue:

1) Sources on a Mac newsgroup should be represented in a form that is both
   transportable and *natural* for Mac users.
2) On the other hand, sources should be readable on a UNIX system.
3) BinHex Encoding serves both 1) and 2). The Mac character set and the
   resource file format present some problems to reading the information on the
   UNIX side, but both are well documented.
4) The choice of a compression format is slightly more problematic. IMHO,
   submitters to comp.sources.macintosh should be required to use a compression
   format that can be decompressed by an UNIX host. Stuffit 1.5.1 format is
   well documented, and there exist decompressors for UNIX. Are there any other
   formats for which this condition holds ?

Matthias

- -----
Matthias Neeracher                                      [e-mail]
  "And that's why I am going to turn this world upside down, and make
   of it a fire so *bright* that someone real will notice"
                                -- Vernor Vinge, _Tatja Grimm's World_

+++++++++++++++++++++++++++

From: [e-mail] (Matt Mora)
Date: 22 Jun 92 16:16:44 GMT
Organization: SRI International, Menlo Park, California

In article <[e-mail]> [e-mail] (Steve Dorner) writes:
>[e-mail] (David Fry) writes:
>>If the USENET gods insist we can't send .hqx files to comp.sources.mac

>The only god we have to worry about is the moderator of comp.sources.mac.

>I, too, think it's silly to ban .hqx files from the group.


Here! Here! I think its stupid to put so many conditions on a gift. Let the
poster post what ever she wants since she is nice enough to freely give
out source code. Why punish her by making her follow some stupid rules?
I hope all sources come by as hqx files, including the project file and
resources need to run the project. (if it needs them). Also if its just
a routine, it would be nice to include a test program to show how it works.

Matt

- --
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________

+++++++++++++++++++++++++++

From: [e-mail] (Gregory G. Woodbury)
Date: 23 Jun 92 04:15:05 GMT
Organization: Wolves Den UNIX

[e-mail] (David Fry) writes:
><[e-mail]> I wrote:
>>In the heat of the discussion about comp.sources.mac it becomes obvious
>>that there is a problem with the way that sources for Macintosh programs
>>are packaged.
>>
>Why is this necessary? If the answer is so that non-MacPeople will
>allows us to send our Mac source to comp.sources.mac, I say "tough for
>them," let's just send .hqx files. . . .
>If the USENET gods insist we can't send .hqx files to
>comp.sources.mac, then send them to comp.binaries.mac or some other
>forum.  Make them available for ftp.

    There is no reason that sources couldn't be posted in .hqx form
on comp.sources.mac (other than the moderators reluctance to declare a
change based on a situation that has changed dramatically since the
group was first established)  BUT, which format are you going to use?

    I am still using an older version (3.??) of Think C (lazy about
upgrading and the boss is cheap) and can't really deal with project
files from the latest and greatest version.  There is also no way for
me to benefit from the similar packageing provided by MPW.  There are
also other development systems out there that use incompatible file
formats.  It is not just a question of .hqx files.

    Additionally, there are a lot of folks out there who don't have
access to FTP!  Even anonymous UUCP is a problem for some folks.  I have
an anonymous uucp archive here at wolves, and the mac stuff is hardly
ever touched.  [9194937111 login:uanon (no passwd) /news/Archives/toc.Z
or /news/Archives/Binaries/mac/MacBin.index]

>I know there are other environments out there, but they are vastly
>outweighed by MPW and THINK.

    So, you'll just ignore them?

>>3.  Binary data (like resources) should appear in standard .hqx form.
>>Something similar is a standard occurrence in sources appearing on the
>>comp.sources.x groups for binary based data.
>
>If we're going to give in and post Binhex data for this, why not just
>distribute the whole thing in binhex?

    Because we are dealing with data that is hard to deal with in a
plaintext format.  Bitmaps for X and other stuff in various groups that
is not well represented in ASCII should be encoded.

>>There is enough desire for Mac sources to be made available, that it is
>>well worth *our* effort to get this worked out so that they can be made
>>available.
>
>I think people can make their sources available already.

Sure, they can, but for some reason, they *are not* doing so!

I suspect it is due to the dearth of postings in comp.sources.mac.  In
fact, there is a source package that was just posted to
comp.binaries.mac!  There is no reason (other than Roger's opinion) for
it to have not be at least cross-posted to comp.sources.mac as well.


Additionally, you asked why do it in ASCII.  This machine is not a Mac,
and there isn't a mac near it to make it easy to decode the stuff.  If I
get something that I want to take a look at in the mac groups, I have to
mail it to my office, spool it there, ftp it somehow to the mac, decode
it (after recombining the parts), unstuff/uncompress it, and then look
at it to see if I can interpret it in the development environment I
have.

Since most of my reading and research is done here, I'd much rather see
the ASCII code of the programs simply to see how the various programmers
do the things that I seem to have trouble with (despite having all the
Apple books and a fair collection of others as well.)  [For example, I
have some scrolling text in a window - e.g. a debugging log  - and I
have a little bit of trouble totally comprehending how the scroll bars
and their values are used to allow full scroll-bar functionality.  I
have it working after a fashion, but it's not the same as all the other
mac programs do, and the users complain that they have to think twice
about how this program differs.   Two or three programs that do the
scroll-bars right would be invaluable to me in terms of showing me how
to do them right.]

I'm also fairly sure that there are a fair number of non-Mac-programmers
would be interested in being able to read some mac sources to be able to
learn a bit about mac programming in their spare time.  Event-driven
interfaces are getting more and more common, and techniques developed
for the Mac are applicable all over the programming map.

There is a distressing tendancy for the Mac development world to get too
wrapped up in itself and forget that there are lots of other people out
there who would like to avoid re-inventing the wheel.  There is much
more to usenet than comp.*.mac.* groups!
- --
Gregory G. Woodbury @ The Wolves Den UNIX, Durham NC
UUCP: ...dukcds!wolves!ggw   ...duke!wolves!ggw           [use the maps!]
Domain: [e-mail]     [e-mail]
[The line eater is a boojum snark! ]           <standard disclaimers apply>

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Neeracher)
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: Tue, 23 Jun 1992 11:44:27 GMT

In article <[e-mail]> [e-mail] (Gregory G. Woodbury) writes:
>    There is no reason that sources couldn't be posted in .hqx form
>on comp.sources.mac (other than the moderators reluctance to declare a
>change based on a situation that has changed dramatically since the
>group was first established)  BUT, which format are you going to use?

A valid objection. How about the following:

- - 'TEXT' files for sources
- - ResEdit or {SARez,Rez} files for resources.
- - 'PICT' or 'MPNT' for graphic data
- - TextEdit, MacWrite, or MS Word files for documentation.
- - Optionally Think or MPW project files, as long as Text files are also
  included.
- - Encoded in BinHex/Stuffit Classic format

>>I know there are other environments out there, but they are vastly
>>outweighed by MPW and THINK.
>
>    So, you'll just ignore them?

I don't know whether it would be a good idea to distribute SmallTalk, Neon, or
J sources via comp.binaries.mac

>>If we're going to give in and post Binhex data for this, why not just
>>distribute the whole thing in binhex?
>
>    Because we are dealing with data that is hard to deal with in a
>plaintext format.  Bitmaps for X and other stuff in various groups that
>is not well represented in ASCII should be encoded.

As I said before, even Mac *text* file can not be that well represented in
ASCII.

>Additionally, you asked why do it in ASCII.  This machine is not a Mac,
>and there isn't a mac near it to make it easy to decode the stuff.  If I
>get something that I want to take a look at in the mac groups, I have to
>mail it to my office, spool it there, ftp it somehow to the mac, decode
>it (after recombining the parts), unstuff/uncompress it, and then look
>at it to see if I can interpret it in the development environment I
>have.

.hqx files are handled by mcvert
.sit files are handled by unsit

Both of these are UNIX programs. So it seems to me that there *is* a subset of
formats that is easily decoded on both the Mac and the UNIX side.

>I'm also fairly sure that there are a fair number of non-Mac-programmers
>would be interested in being able to read some mac sources to be able to
>learn a bit about mac programming in their spare time.  Event-driven
>interfaces are getting more and more common, and techniques developed
>for the Mac are applicable all over the programming map.

But these non-Mac-programmers will at least need to get their hands in Inside
Macintosh, unless you want to rule that sources posted to c.s.m shall not
contain any Toolbox calls :-)

Matthias

- -----
Matthias Neeracher                                      [e-mail]
  "And that's why I am going to turn this world upside down, and make
   of it a fire so *bright* that someone real will notice"
                                -- Vernor Vinge, _Tatja Grimm's World_

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Date: 23 Jun 92 17:37:13 GMT
Organization: The Royal Society for Putting Things on Top of Other Things

In article <[e-mail]> [e-mail] (Matthias Neeracher) writes:
>In article <[e-mail]> [e-mail] (Gregory G. Woodbury) writes:
>>    There is no reason that sources couldn't be posted in .hqx form
>>on comp.sources.mac (other than the moderators reluctance to declare a
>>change based on a situation that has changed dramatically since the
>>group was first established)  BUT, which format are you going to use?
>
>A valid objection. How about the following:
>
>- 'TEXT' files for sources
Unfortunately, Mac sources (esp. from MPW) make use of Mac-specific 8-bit
ASCII characters.  What to do?

>- ResEdit or {SARez,Rez} files for resources.
Rez descriptions would be the best, I think, unless SARez/SADeRez aren't
freely available.  Are they on ftp.apple.com?

>- 'PICT' or 'MPNT' for graphic data
              ^^^^
Please, not MacPaint (may it rest in peace) format, although it's easy enough
to decode.  I believe that it is very important to allow full Quickdraw
generality, and PICT is also quite easy to deal with.

>- TextEdit, MacWrite, or MS Word files for documentation.
I think the best for for short docs would be TeachText, using pictures as
needed.  For more complex docs MS Word is the way to go, much as I hate to
say it.

>- Optionally Think or MPW project files, as long as Text files are also
>  included.
I'd love to see a THINK project "decompiler" that emitted some standardized
text-based description of a project.

>- Encoded in BinHex/Stuffit Classic format
Agreed.

- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s++ e+ h- pv     |         Chicago, IL  60637

+++++++++++++++++++++++++++

From: [e-mail] (Stephen Uitti)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Date: Wed, 24 Jun 1992 00:04:32 GMT

In article <[e-mail]> [e-mail] writes:
>>- 'TEXT' files for sources
>Unfortunately, Mac sources (esp. from MPW) make use of Mac-specific 8-bit
>ASCII characters.  What to do?

Think C sources too.  We like to put copyright symbols right into the
comments.

>>- ResEdit or {SARez,Rez} files for resources.
>Rez descriptions would be the best, I think, unless SARez/SADeRez aren't
>freely available.  Are they on ftp.apple.com?

Rez also generates characters with the MS bit set.  Sometimes it even
does this (in comments) when it is inappropriate.  Certainly, if you
put a character (like the copyright symbol) into a text string, you
will get an 8th bit set character in the Rez file.

>>- TextEdit, MacWrite, or MS Word files for documentation.
>I think the best for for short docs would be TeachText, using pictures as
>needed.  For more complex docs MS Word is the way to go, much as I hate to
>say it.

Teach text is a pain to write, especially with pictures.  Almost anyone
can read or write the older MacWrite format.

>>- Optionally Think or MPW project files, as long as Text files are also
>>  included.
>I'd love to see a THINK project "decompiler" that emitted some standardized
>text-based description of a project.

As long as there was a way to recompile it into a project file.  BinHex
works pretty well.

I would just say, use stuffit/binhex.  Compactor/binhex is also good.
An archive should choose one.

Stephen.
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Neeracher)
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: Wed, 24 Jun 1992 15:12:02 GMT

In article <[e-mail]> [e-mail] (Stephen Uitti) writes:
>In article <[e-mail]> [e-mail] writes:
>>>- 'TEXT' files for sources
>>Unfortunately, Mac sources (esp. from MPW) make use of Mac-specific 8-bit
>>ASCII characters.  What to do?
>
>Think C sources too.  We like to put copyright symbols right into the
>comments.

Yes, that's why I wrote 'TEXT', not text :-) With 'TEXT file, I mean a fiel
based on teh Macintosh 8 bit alphabet.

>I would just say, use stuffit/binhex.  Compactor/binhex is also good.
>An archive should choose one.

The problem with Compactor/Binhex is that I don't know how good Compact Pro
format can be decoded on UNIX systems.

Matthias

- -----
Matthias Neeracher                                      [e-mail]
      "C'THULHU FOR PRESIDENT
       For people who are tired of voting the LESSER of two evils !"
           -- Greble Dagmar <[e-mail]>

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik (High Priest of SSSM))
Date: 25 Jun 92 03:53:36 GMT
Organization: Secret Society of Software Mungers

In article <[e-mail]>, [e-mail]
(David Fry) writes:
> These are all good ideas, but I again wonder why this is necessary. I
> think it's the habit of the net.community to build structure and
> formalism just because we enjoy the process. I think it would be cool to have
> a program that I could point at a set of files and have it produce an
> ASCII representation, but I don't think the value of this is worth the
> effort, not to mention all the future effort of people straining to
> conform to it, and the future nitpicking of people who don't conform
> to it.

True, too complicated and convoluted standards will never catch. Binhex/Stuffit
seems to work fine, so I really wonder why the need to define yet another
standard?

The best standards appear automatically from long term practical use.

Cheers,
Kent


+++++++++++++++++++++++++++

From: [e-mail] (Dave Glowacki)
Date: 26 Jun 1992 00:20:05 GMT
Organization: University of California, Berkeley

In article <[e-mail]> [e-mail] (Steve Dorner) writes:
>[e-mail] (David Fry) writes:
>>If the USENET gods insist we can't send .hqx files to comp.sources.mac
>
>The only god we have to worry about is the moderator of comp.sources.mac.

Actually, you need to worry about the USENET administrators.  Many news admins
don't carry comp.binaries.* specifically BECAUSE it contains non-human readable
postings.  If news admins at major net-hubs  stop distributing comp.sources.mac
because it contains binaries, the newsgroup will effectively cease to exist.
- --
Dave Glowacki                 [e-mail]                   UCBerkeley

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Neeracher)
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: Fri, 26 Jun 1992 16:17:28 GMT

In article <[e-mail]> [e-mail] (Dave Glowacki) writes:
>In article <[e-mail]> [e-mail] (Steve Dorner) writes:
>>[e-mail] (David Fry) writes:
>>>If the USENET gods insist we can't send .hqx files to comp.sources.mac
>>
>>The only god we have to worry about is the moderator of comp.sources.mac.
>
>Actually, you need to worry about the USENET administrators.  Many news admins
>don't carry comp.binaries.* specifically BECAUSE it contains non-human readable
>postings.  If news admins at major net-hubs  stop distributing comp.sources.mac
>because it contains binaries, the newsgroup will effectively cease to exist.

Are there any news admins at major net hubs that don't carry comp.binaries.* ?
And it's not that comp.sources.macintosh would be the only .sources. group to
carry encoded files: comp.sources.hp48 does this already.

And, look at it this way: There *are* no text files. All there is are *binary*
encoded text files. ASCII and BinHex/Stuffit are just two different ways to
binary encode a text file.

Matthias

- -----
Matthias Neeracher                                      [e-mail]
  "I recognize that a class of criminals and juvenile delinquents
   has taken to calling themselves 'hackers', but I consider them
   irrelevant to the true meaning of the word; just as the Mafia
   calls themselves 'businessmen' but nobody pays that fact any
   attention." -- Robert Bickford <[e-mail]>

+++++++++++++++++++++++++++

From: [e-mail] (Peter N Lewis)
Organization: NCRPDA, Curtin University
Date: Sat, 27 Jun 1992 06:44:49 GMT

In article <[e-mail]>,
     [e-mail] (Dave Glowacki) wrote:
>
> In article <[e-mail]>
       [e-mail] (Steve Dorner) writes:
> >[e-mail] (David Fry) writes:
> >>If the USENET gods insist we can't send .hqx files to comp.sources.mac
> >
> >The only god we have to worry about is the moderator of comp.sources.mac.
>
> Actually, you need to worry about the USENET administrators.  Many news
> admins don't carry comp.binaries.* specifically BECAUSE it contains
> non-human readable postings.  If news admins at major net-hubs  stop
> distributing comp.sources.mac because it contains binaries, the newsgroup
> will effectively cease to exist.

Ummm, it doesn't exist now!  Nothing ever comes out of it as it is!  At the
moment sources go thru comp.binaries.mac, so if they were moved to
comp.sources.mac and those same administrators who currently don't
distribute cbm stop distributing csm what difference does it make?  At
least they will be not distributing files in the correct group instead of
not distributing them in the wrong group!
   Peter.

_______________________________________________________________________
Peter N Lewis, NCRPDA, Curtin University       [e-mail]
GPO Box U1987, Perth WA 6001, AUSTRALIA             FAX: [phone]

---------------------------

From: [e-mail] (VAUGHN KEITH DAVIS)
Subject: SendFinderOpen
Date: 17 Jun 92 15:36:23 GMT
Organization: Georgia Institute of Technology

I trying to send an 'OpenSelection' Apple Event to the Finder in order to
launch an application. I'm using the code clip on the Feb'92 Developer CD.
I get an error of -903 from the AESend call.

Does someone have code for a standalone program which would launch a file
or application by using the Apple Events. I'm eventually going to use the
code in a larger application to launch a background appl to perform some
rendering.

Thanks.

- --
VAUGHN,KEITH D
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:     ...!{allegra,amd,hplabs,ut-ngp}!gatech!prism!kv2
Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 26 Jun 92 04:18:28 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (VAUGHN KEITH DAVIS) writes:
>
> I trying to send an 'OpenSelection' Apple Event to the Finder in order to
> launch an application. I'm using the code clip on the Feb'92 Developer CD.
> I get an error of -903 from the AESend call.
>
> Does someone have code for a standalone program which would launch a file
> or application by using the Apple Events. I'm eventually going to use the
> code in a larger application to launch a background appl to perform some
> rendering.

If you are launching an application, use the LaunchApplication call.  It will
work even without the Finder running (which could be conceivable on systems
with an alternate Finder).  It's faster, easier and better.  See the Process
Manager chapter (29) of IM6.

Your problem sounds like your application's SIZE resource.  You need to set
the highLevelEventAware bit to be able to use AE.

Jon
kAERegistrar


---------------------------

From: [e-mail] (Eric Schlegel)
Subject: garbage sound from SndPlay
Date: 17 Jun 92 16:14:51 GMT
Organization: Microsoft Corp.

OK, I give up on this one, let's see if any netfolk can help...

I'm trying to play a 'snd ' resource asynchronously using SndPlay. I use the
following code to create a sound channel and then play the sound:

SndChannelPtr    psc;

SndNewChannel(&psc, sampledSynth, initMono | initNoInterp, NULL);
SndPlay(psc, mySndHandle, true);

The first time I do this after booting the Mac, the sound comes out with lots
of static and crackles, and it's very hard to make out the sound being played.
The second time usually has some static, and after that the sound is fine. I
can quit the app and restart it, and the sound is OK the very first time; it's
just right after the Mac is booted that I have problems.

This is System 7.0.1 with TuneUp 1.1.1 on a Mac IIcx.

Any suggestions as to why this happens and what I can do about will be
gratefully accepted... Thanks!

- -eric
- -------
My opinions, not Microsoft's.

+++++++++++++++++++++++++++

From: [e-mail] (Paul Potts)
Date: 17 Jun 92 22:10:15 GMT
Organization: Instructional Technology Laboratory, University of Michigan

In article <[e-mail]> [e-mail] (Eric Schlegel) writes:
>OK, I give up on this one, let's see if any netfolk can help...
>
>I'm trying to play a 'snd ' resource asynchronously using SndPlay. I use the
>following code to create a sound channel and then play the sound:
>
>SndChannelPtr    psc;
>
>SndNewChannel(&psc, sampledSynth, initMono | initNoInterp, NULL);
>SndPlay(psc, mySndHandle, true);

This little fragment doesn't tell me a whole lot (except that you speak
Hungarian!) but I'll throw out some ideas...
>
>The first time I do this after booting the Mac, the sound comes out with lots
>of static and crackles, and it's very hard to make out the sound being played.

Are you running Virtual Memory? It can cause noisy sound. There are ways to
keep VM from doing its thing temporarily. Also, make sure the handle to
the sound won't move while playing. Lock it.

Jim Reekes, the sound manager guru from Apple (who, I'm told, looks a bit like
me) will probably throw in his $.02 sometime, but you might try these things
too.


- --
The essence of OOP: "With all this horse manure, I know there's got to be
                     a pony in here somewhere!"
Paul R. Potts, Software Designer --- [e-mail] <--- me!

+++++++++++++++++++++++++++

From: [e-mail] (The Web)
Date: 19 Jun 1992 08:54:35 GMT
Organization: U.C. Berkeley Open Computing Facility

>OK, I give up on this one, let's see if any netfolk can help...
>
>I'm trying to play a 'snd ' resource asynchronously using SndPlay. I use the
>following code to create a sound channel and then play the sound:
>
>SndChannelPtr  psc;
>
>SndNewChannel(&psc, sampledSynth, initMono | initNoInterp, NULL);
>SndPlay(psc, mySndHandle, true);

>From Inside Mac volume V page 477:

"SndNewChannel opens a new channel.  If you pass NIL for the chan parameter,
the Sound Manager opens a channel for you and returns a pointer to it."

If you don't pass nil, it assumes that the memory has been allocated.  What does psc initially point to?  The compiler won't necessarily set this to zero
automatically for you.  (But after a few tries, you might get lucky).

This should fix your problem:

SndChannelPtr    psc = 0;

SndNewChannel(&psc, sampledSynth, initMono | initNoInterp, NULL);

- -E. Wylie


+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 25 Jun 92 07:26:12 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Eric Schlegel) writes:
>
> OK, I give up on this one, let's see if any netfolk can help...
>
> I'm trying to play a 'snd ' resource asynchronously using SndPlay. I use the
> following code to create a sound channel and then play the sound:
>
> SndChannelPtr    psc;
>
> SndNewChannel(&psc, sampledSynth, initMono | initNoInterp, NULL);
> SndPlay(psc, mySndHandle, true);
>
> The first time I do this after booting the Mac, the sound comes out with lots
> of static and crackles, and it's very hard to make out the sound being played.
> The second time usually has some static, and after that the sound is fine. I
> can quit the app and restart it, and the sound is OK the very first time; it's
> just right after the Mac is booted that I have problems.
>
> This is System 7.0.1 with TuneUp 1.1.1 on a Mac IIcx.
>
> Any suggestions as to why this happens and what I can do about will be
> gratefully accepted... Thanks!

You didn't initialize the psc in your code.  Add this line:

  psc = nil;

If you don't have real data allocated for this pointer, then all hell can
run amuck.  If you did allocate data then you must set the qLength field.
Also, try using the standard system 'snd ' resource to rule out any problems
with your sounds.  And don't ignore the errors (e.g. your code doesn't).

- -----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | RAll opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc.S



+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 25 Jun 92 07:26:36 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Eric Schlegel) writes:
>
> OK, I give up on this one, let's see if any netfolk can help...
>
> I'm trying to play a 'snd ' resource asynchronously using SndPlay. I use the
> following code to create a sound channel and then play the sound:
>
> SndChannelPtr    psc;
>
> SndNewChannel(&psc, sampledSynth, initMono | initNoInterp, NULL);
> SndPlay(psc, mySndHandle, true);
>
> The first time I do this after booting the Mac, the sound comes out with lots
> of static and crackles, and it's very hard to make out the sound being played.
> The second time usually has some static, and after that the sound is fine. I
> can quit the app and restart it, and the sound is OK the very first time; it's
> just right after the Mac is booted that I have problems.
>
> This is System 7.0.1 with TuneUp 1.1.1 on a Mac IIcx.
>
> Any suggestions as to why this happens and what I can do about will be
> gratefully accepted... Thanks!

You didn't initialize the psc in your code.  Add this line:

  psc = nil;

If you don't have real data allocated for this pointer, then all hell can
run amuck.  If you did allocate data then you must set the qLength field.
Also, try using the standard system 'snd ' resource to rule out any problems
with your sounds.  And don't ignore the errors (e.g. your code doesn't).

- -----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | RAll opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc.S

---------------------------

End of C.S.M.P. Digest
**********************